Release 10.1A: OpenEdge Development:
Progress Dynamics Basic Development

Consider distributed database access

When designing a new database, considering the implications of distributed database access is critical. It is no longer practical (or even possible) to have the direct record-by-record control over locks and scoping that older OpenEdge® applications generally have. Records are read from the database in batches. They are then passed in a temp-table to a client running on a different machine. Changes are made without any direct connection to the database. Then those changes are passed back to the server to be updated in a server-side transaction. This mechanism is not particular to Progress Dynamics or to SmartObjects, but simply a consequence of managing data in a distributed environment.

Because of that mechanism, it is neither desirable nor possible to hold record locks for an entire client-side update operation. A few additional database fields combined with standard application logic can make it much easier to manage transactions in this environment. For example, put an Updating flag field in a header record for an order. Then have the order update logic in the standard beginTransactionValidate procedure of the SDO or SBO first check this flag before it begins executing the business logic associated with an order. When the update logic sets the flag, it can effectively “reserve” all the related records associated with an update without using actual transaction locking.

If the update logic checks this flag before allowing an update to begin, then two users cannot update the same set of related records concurrently. Alternatively, you can set such a flag in a separate transaction when one or more records are read for an update transaction. This effectively locks out other users from starting an update without using conventional record locks.

Such additional fields are a useful part of any new database design. They can also be a useful, or even necessary, addition to an existing database.